When an algorithm module is tested to meet various performance requirements and criteria, this testing is usually performed in a single-channel mode where test software dedicated to the execution and verification of the algorithm module is implemented. Generally, no additional processing is performed by the microprocessor in testing the algorithm. Traditional unit testing may verify that the algorithm meets various performance and/or functional requirements. However, when the algorithm is used in a complete system design, the algorithm is no longer an isolated process on a dedicated microprocessor. Oftentimes, the environment may introduce additional characteristics and factors that have not been tested or considered in traditional unit testing.
For example, the presence of Interrupt Service Routines (ISR) may cause the algorithm to be interrupted. ISR generally refers to a software routine that is activated to respond to an interrupt. The status of various registers prior to a call to an algorithm may be different than they were in the unit testing. In addition, scratch space used by the algorithm is likely to be modified by other processes executing between calls to the algorithm. This is less likely to occur in unit testing where the algorithm is isolated. If the algorithm does not restore registers correctly upon return, a caller in a system design may be affected whereas the unit test software may not be affected. If the algorithm modifies memory not allocated, a system design is more likely to be affected since much of the processor's memory is unused during unit testing. These types of problems as well as other problems are costly when not discovered or addressed until a system test. They are even more costly if not identified until a general release.
Therefore, there is a need in the art of compliancy testing for a more efficient method and system for testing algorithms for proper functioning in a real-time software system or environment.